Recent advances in computer performance have enabled graphic systems to provide more realistic graphical images using personal computers and home video game computers. In such graphic systems, some procedure must be implemented to “render” or draw graphic primitives to the screen of the system. A “graphic primitive” is a basic component of a graphic picture, such as a polygon, a triangle, a line or a point. All graphic pictures are formed with combinations of these graphic primitives. Many procedures may be utilized to perform graphic primitive rendering.
Early graphic systems displayed images representing objects using just colored polygons. That is, textures, bumps, scratches, or other surface features were very expensive to model because they had to be drawn with individual polygons. In order to improve the quality of the image, texture mapping was developed to model the complexity of real world surface images. In general, texture mapping is the mapping of an image or a function onto a surface. Texture mapping is a relatively efficient technique for creating the appearance of a complex image without the tedium and the high computational cost of rendering the actual three dimensional detail that might be found on a surface of an object.
Prior Art FIG. 1 illustrates a graphics pipeline with which texture mapping may be performed. As shown, the present embodiment may be divided into a plurality of modules including a buffer 150, a transform module 152, a lighting module 154, a rasterization/texture module 156 with a set-up module 157, and a frame buffer 158.
During operation, the buffer 150 is used for gathering and maintaining a plurality of vertex attribute states such as position, normal, colors, texture coordinates, etc. Completed vertices are processed by the transform module 152 and then sent to the lighting module 154. Typically, the transform module 152 is used to map vectors from an object coordinate space into the screen coordinate space. The lighting module 154 calculates the surface color at the vertex based on the surface normals and material properties.
The output of the lighting module 154 is screen space data suitable for the set-up module 157, which, in turn, calculates primitive extents. Thereafter, rasterization/texture module 156 iterates through all of the pixels contained within the primitive and maps any required textures onto the primitive. The output of the rasterization/texture module 156 is then sent to a frame buffer 158 for storage prior to being output to a display device (not shown).
Prior Art FIG. 2 illustrates the rasterization/texture module 156, in accordance with the prior art. The rasterizer 200 passes configuration data for control registers to the texture module 201. In response to the receipt of configuration data, the texture module 201 is configured to operate in a particular mode as will be described shortly. This configuration data is also passed to the texture environment module 206. The rasterizer 200 also generates texture coordinates for all of the pixels that comprise a primitive. In response to the receipt of such texture coordinates, the texture module 201 is adapted to calculate texture cache addresses utilizing an address calculation module 202. Such texture cache addresses may be then utilized for looking up corresponding textures in the form of texels from memory 204 utilizing a texture cache 203. Upon receipt of a texture cache address, the texture cache 203 outputs the associated texels to the texture filtering module 205 if the texels are already present inside the texture cache 203. If the associated texels are not present in the texture cache 203, texture requests are sent to the memory 204. In response to the texture requests, the memory 204 will send the associated texels to the texture cache 203. The texture cache 203 retains a copy of the texels so that future requests for the same texels may be serviced without requiring accesses to the memory 204, and sends the texels on to the texture filtering module 205. Based on the current configuration, and in response to the receipt of texels from the texture cache 203, the texture filtering module 205 adapts texels to map to pixels associated with the primitives.
The texture environment module 206 is configured by the configuration data from the texture module 201. The filtered texels from the texture filtering unit 205 are blended by the texture environment module 206 with other pixel data (such as other, previously referenced textures). Once all texture blending operations are completed, the pixel data is passed on to the frame buffer (not shown).
As mentioned above, each of the components in the texture module 201 may operate in various “states” or “modes.” By this design, the components of the texture module 201 may process the texels in various ways for each subject pixel. For example, the address calculation module 202 may allow various dimensionality textures (i.e. 1-D, 2-D, 3-D, etc), and may calculate addresses for textures of various sizes (i.e. width, height, depth, etc.). Moreover, the address calculation module 202 and texture cache 203 may handle different texel formats (i.e. 8 bit texels, 16 bit texels, DXT compressed texels, palettized texels, etc). Additionally, the address calculation module 202 may support different methods for accommodating requests for texels beyond the defined texture size (i.e. wrapping, clamping, border colors, etc). Still yet, each of the components in the texture module 201 may operate in different filtering modes (i.e. no filtering, bilinear filtering, trilinear filtering, anisotropic filtering, etc). These examples are typical for a texture module 201, but do not represent a necessary or complete list of modes or states. Of course, any combination of features may be enabled, disabled, and/or altered based on a particular mode of operation.
Because of the amount of configuration data required to initialize the state of the texture module 201, a typical system allows programmed combinations of states to be created. Further, an exemplary system may allow these programmed combinations of states to be referenced via a “texture ID”. In such a system, configuration data may be used to establish the state (e.g., a particular dimensionality, a particular size, a particular texel format, etc) for a given texture ID (e.g. texture ID 0). Then, further configuration data may be used to establish the state for another texture ID (e.g. texture ID 1). In such a system, the rasterizer 200 may then provide a texture ID with the texture coordinates. For example, one primitive may use texture ID 0, a subsequent primitive may use texture ID 1, and so on. If a primitive again requires texture ID 0, it may not be necessary to resend any additional configuration information since this texture ID was previously configured. In this way, multiple primitives with differing texture modes could be referenced with minimal reprogramming of configuration data. Not all texture modules 201 support texture ID's; texture ID's are merely one method that has been used to try to minimize the amount of configuration data which must be programmed.
In recent prior art, the texture environment 206 has been replaced with pixel shading hardware. Prior Art FIG. 3 illustrates an example of a modern, high performance system. The rasterizer 200 and texture module 201 still exist in the high performance system (see rasterizer 350 and texture module 351). However, the texture environment module has been replaced with a shader module 352. One of the key advantages of this architecture is that processing for a primitive can “loop” (i.e. the texels resulting from one texture lookup can influence the location of the texels in a subsequent texture lookup). In particular, the processing can loop many times and use a variety of math operations to blend texture and color data, and to compute new texture coordinates, allowing a much more complicated and visually rich resulting image than was available with the architecture in Prior Art FIG. 2. The configuration data which controls this looping and the associated math operations is typically referred to as a “shader program” since it bears a resemblance to a “program” such as a general purpose computer would execute.
With the expanding options enabled by the architecture in Prior Art FIG. 3, there is an associated increase in the amount of configuration data required to achieve a desired effect. Even in systems utilizing texture ID's as described above, the amount of configuration data required to configure the texture ID's and shader program can require a significant amount of time to push down the pipeline through the texture module 351 and the shader 352. Thus, there is a need to accommodate the programmability of recent texture and shader modules without being inhibited by the size of associated programs.